home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 872 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.3 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: abell@mindspring.com (Andrew Bell)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Quick questions
  5. Date: 27 Mar 1996 15:46:56 GMT
  6. Organization: MindSpring Enterprises
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4jajk2$17aq@mule1.mindspring.com>
  9. References: <4j5b26$1e7a@mule1.mindspring.com> <4j7a64$l9i@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Nntp-Posting-Host: abell.mindspring.com
  12. X-Newsreader: Forte Agent .99.82
  13. Content-Length: 3457
  14. X-Lines: 69
  15. Originator: clamage@taumet
  16.  
  17. clamage@Eng.sun.com (Steve Clamage) wrote [but much edited by me]:
  18. >In article 1e7a@mule1.mindspring.com, abell@mindspring.com (Andrew Bell) writes:
  19. >>About casting operators]
  20. >[[Are you asking] can you define
  21. >a conversion operator from a user-defined class to a predefined type
  22.  
  23. No, I'd want to go the other way.  In the case of "pure wrapper"
  24. classes (as I defined in my earlier post), one might want an automatic
  25. cast from the original to the wrapper.  In my case, I have created a
  26. class to wrap around an OS-defined struct, to give it access safety
  27. (the particular class contains a type specifier and a union) and
  28. smarter access as well as constructors.
  29.  
  30. I'd like to have a casting operator that would allow me to convert the
  31. original struct to the pure wrapper automatically.  (but you can't
  32. always get what you want...)  A constructor works differently than a
  33. casting operator; in this case, it would force the creation of an an
  34. (algorithmically) unnecessary duplicate object.  Admittedly, it's only
  35. relevant for pure wrapper classes, but is that such a rare concept?
  36.  
  37. It's always seemed a little odd to me that you can add operators to a
  38. class outside the class structure, even when they might modify the
  39. object (such as ostream operator<<...), but not non-virtual functions.
  40. It is, after all, this restriction against defining member functions
  41. externally that leads to my need for pure wrapper classes (and my
  42. desire for casting support to them) in the first place.
  43.  
  44. I can do what I need with dangerous casts
  45.     PureWrapperClass &wrapper = (PureWrapperClass &)
  46.         baseStruct;
  47. but it isn't obvious without lots of hunting that this is in fact
  48. safe.  Also, sometimes I might not want to allow the conversion (throw
  49. an exception in the conversion operator),, which this approach doesn't
  50. allow.
  51.  
  52. >I assume you mean a class like
  53. >    class Short { short val; };
  54. >with non-virtual member functions added. You can't assume the size and
  55. >alignment of the class will be the same as its only data member, and no,
  56. >the standard provides no special support for this special case.
  57.  
  58. Seems like if you only have one data member and no virtual functions,
  59. there's no reason to arbitrarily restrict it to a greater alignment
  60. level, save maybe to make compiler programmer's lives (and maybe
  61. debugger programmer's lives) trivially easier.   (For that matter, is
  62. there really a good reason to make it more restrictive than the most
  63. restrictive member element regardless of the number of elements?  I
  64. suppose there's making the bitwise copy constructors a little more
  65. efficient, though that doesn't hold for the single member case.)
  66.  
  67. >>4) With RTTI, a derived class that doesn't change any virtual member
  68. >>funcs or add any properties to a base class still evaluates to a
  69. >>different object type, correct?
  70. >Yes. The typeids of two types compare equal if and only if they are
  71. >the same type. Base and derived classes are not ever the same type.
  72.  
  73. Fair enough, although in this case RTTI forces the creation of an
  74. additional vtable that wouldn't normally be necessary.  Since the
  75. general criterion for RTTI support in a class in the first place is
  76. the existence of any virtual functions (and thus a vtable), it doesn't
  77. seem like it would be too unreasonable to make classes with identical
  78. vtables evaluate to the same thing.  Adding an operator to a class
  79. (externally) doesn't change its identity; should a non-virtual member
  80. function do so?
  81.  
  82. Andrew Bell
  83. abell@mindspring.com
  84.  
  85.  
  86.  
  87.  
  88. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  89. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  90. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  91. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  92. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  93.